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DETAILED ACTION 

This final office action is responsive to the amendments and arguments filed on 
01/032008 in reply to examiner's office action mailed on 10/03/2007. 
Claims 14-15 and 23 have been cancelled; 
Claims 24-27 are newly added; 
Claims 1-13, 16-22 and 24-27 are now pending; 

Response to Arguments 

Applicant's arguments and amendments filed on January 3, 2008 have been 
carefully considered but they are not deemed fully persuasive. 

Applicant's arguments are deemed moot in view of the following new grounds of 
rejection as explained here below, necessitated by Applicant's substantial amendments to 
the claims which significantly affected the scope thereof, i.e., by incorporating the 
limitations of claims 14 and 15 into independent claim 1, amending claim 12, as well as 
the cancellation of claims 14 and 15, the amendments have changed the scope of 
dependent claims 2-11, 13 and 16-22, and will require further search and consideration. 

Accordingly, THIS ACTION IS MADE FINAL. See MPEP 706.07(a). Applicant 
is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

1 . Objections to the drawings and abstract are withdrawn after a careful review of 
applicant's amendments to the drawings; 



2. Section 102(b) rejections of claims 1-8, 10-13, 16-18 and 23 are maintained. 
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Regarding claims 1-8, 10-13, 16-18 and 23, applicant argues that the claim 
element "a client identifier" that is included in both a request for storage and a response 
from said store computer is neither taught by the prior art references "The Mirage NFS 
Router", a technical report by Baker, nor "NAS Switch: A Novel CIFS Server 
Virtualization" by Katsurashima, or IETF RFC 1094, "Network File System Protocol 
Specification, Version 2.0", nor RFC 791 "Internet Protocol". 

However, the examiner disagrees with the applicant's argument and maintains the 
rejections for the following reasons. 

First of all, the newly added claim clement "a client identifier" was not present in 
the original application disclosure, raising an issue of new matter under 35 U.S.C. 1 12, 
first paragraph, see MPEP 706.03(o). 

Secondly, the newly added claim element of "a client identifier" that is included 
in a request for storage, and a response from said store computers is disclosed in the 
newly introduced prior art reference U.S. patent application publication 2002/0120763 to 
Miloushev et al., hereinafter referred to as "Miloushev". 

Miloushev discloses in Fig. 3-5 and [0136] that the file switch does not handle 
transactions internally but, instead, examines the requests such as 205, optionally 
modifies request headers such as 200, and forwards the message to a file server. Because 
of this, the file switch preferably does not wait to receive all frames of a message such 
as 205 before forwarding it to the server. This allows the file switch to avoid 
introducing unacceptable latency on multi-frame file protocol transactions, such as 208. 

One of ordinary skill in the art of IP networking can reasonably derived from 
Miloushev' s disclosure above that each frame 201, 202, 203 and 204 of the message 205 
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carries the same source IP address in the IP header, where the source IP address identifies 
the client making the write request 205, and therefore is a client identifier. It can be 
further derived that the response from the file server for the write request carries the same 
client IP address in the destination IP address field of its IP header, i.e., the response 
includes said client identifier. 

It would have been obvious for one of ordinary skill in the art to modify Baker's 
NFS router with Miloushev's teaching such that both a request for storage and its 
corresponding response include the client's IP address as a client identifier. One would 
have been motivated to combine Baker and Miloushev at the time of the invention by the 
fact that both Baker's NFS router and Miloushev's file switch are about ways to 
introduce an intermediate, transparent node into a network of file servers to facilitate the 
scaling of a storage network. The two systems overlap in a significant way, with 
Miloushev's disclosure being more extensive and offering more features. Therefore, the 
combination would have yielded a predictable result with reasonable expectation of 
success. 

Finally, examiner would like to point out that Miloushev's disclosure alone also 
covers all elements of claims 1-8, 10-13 and 16-18 and 23 under 35 U.S.C. 102(b). 

3. Section 103 rejections of claims 9 and 19-22 are maintained for the same reason 
presented above regarding the section 102 rejections of claim 1 and 12 because the claims 
are similarly amended. 
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Specification 

4. The specification is objected to as failing to provide proper antecedent basis for 
the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction 
of the following is required. 

Claims 1 and 12 recite the element "a client identifier" that is not described in the 
specification. 

Claim Rejections - 35 USC § 112 

The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

5. Claims 1-13, 16-22 and 24-26 are rejected under 35 U.S.C. 1 12, first paragraph, 
as failing to comply with the written description requirement. The claim(s) contains 
subject matter which was not described in the specification in such a way as to 
reasonably convey to one skilled in the relevant art that the inventor(s), at the time the 
application was filed, had possession of the claimed invention. 

The amended claims 1 and 12 recite the element "a client identifier" that was not 
included in the original application disclosure and therefore raises an issue of new matter, 
see MPEP 706.03(o). 

Claims 2-11 and 24-25 are dependent on claim 1 and inherit the new matter issue 
of the independent claim. 

Claims 13-22 and 26 are dependent on claim 12 and inherit the new matter issue 
of the independent claim. 
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Claim Rejections - 35 USC §103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 
USPQ 459 (1966), that are applied for establishing a background for determining 
obviousness under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating 
obviousness or nonobviousness. 

This application currently names joint inventors. In considering patentability of 

the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of the 

various claims was commonly owned at the time any inventions covered therein were 

made absent any evidence to the contrary. Applicant is advised of the obligation under 

37 CFR 1 .56 to point out the inventor and invention dates of each claim that was not 

commonly owned at the time a later invention was made in order for the examiner to 

consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) 

prior art under 35 U.S.C. 103(a). 

6. Claims 1-13, 16-22 and 24-26 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. patent application publication no. 2002/0120763 to Miloushev et 
al. (hereinafter "Miloushev"), in view of IETF RFC 1094 ("Network File System 
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Protocol Specification", version 2.0, hereinafter "RFC 1094") and IETF RFC 791 

("Internet Protocol", hereinafter "RFC 791"). 

As to claim 1, Miloushev teaches a communications network comprising: 
at least one communication virtualizer (Fig. 1 and [0053-0054] disclose a file 

switch as an intermediate node that switches network protocol traffic); 

a plurality of network-attached store computers connected to said communication 

virtualizer (Fig. 1 shows multiple file servers 101-107 that is connected to the file switch 

100), 

wherein said plurality of network-attached store computers are configured to 
appear as a single available network-attached store computer (Fig. 1 and [0061] disclose 
that the file switch aggregates the namespaces of multiple independent file servers and 
presents them as a single, unambiguous namespace to network clients); and 

at least one client computer connected to said communication virtualizer (Fig. 1 
and [0125] disclose that clients request file services by communicating to the file switch 
100 using the NFS or CIFS protocols), 

wherein said client computer is adapted to send requests for storage to said 
communication virtualizer (Fig. 1 and [0125] disclose that clients request file services by 
communicating to the file switch 100 using the NFS or CIFS protocols), 

wherein said requests for storage are transmitted as a series of packets, each 
packet comprising a portion of the request for storage ([0054] discloses that one aspect of 
the present invention is a network node that switches network protocol traffic by 
receiving the first network frame of a multiframe file protocol request, examining the file 
protocol header of that request, determining how or where the remaining frames of the 
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request are to be forwarded and then forwarding each of those frames as it is received 
based on this determination) 

wherein each packet comprises a packet sequence number ([0125] disclose that 
clients request file services by communicating to the file switch 100 using the NFS or 
CIFS protocols that run on top of IP, it is inherent that an IP header contains a fragment 
offset, which is equivalent to the sequence number recited in the claim, see RFC 1094 
and RFC 791 for more information), 

wherein said packets comprising a similar request for storage are linked together 
using a request identifier (as said above that said packets are IP packets, it is then 
inherent that each IP header includes a sequence number that links multiple fragmented 
packets of a request together, so the sequence number is equivalent to the request 
identifier recited in the claim), said packet sequence number (the IP header of a packet 
inherently contains a fragment offset that identifies a fragment in a fragmented, multi- 
frame request), and a client identifier, 

wherein each response packet from said store computers includes said client 
identifier(Fig. 3-5 and [0136] that the file switch does not handle transactions internally 
but, instead, examines the requests such as 205, optionally modifies request headers such 
as 200, and forwards the message to a file server. Because of this, the file switch 
preferably does not wait to receive all frames of a message such as 205 before 
forwarding it to the server. This allows the file switch to avoid introducing 
unacceptable latency on multi-frame file protocol transactions, such as 208. One of 
ordinary skill in the art of IP networking can reasonably derived from Miloushev's 
disclosure above that each frame 201, 202, 203 and 204 of the message 205 carries the 
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same source IP address in the IP header, where the source IP address identifies the client 
making the write request 205, and therefore is a client identifier. It can be further derived 
that the response from the file server for the write request carries the same client IP 
address in the destination IP address field of its IP header, i.e., the response includes said 
client identifier), 

and wherein each request for storage comprises a unique request identifier that is 
shared among said packets comprising said similar request (see the reasoning above). 

As to claim 2, Miloushev teaches the communications network of claim I, further 
comprising an internal network of connection nodes connecting said communication 
virtualizer with said network-attached store computers (Fig. 1 and [0124] discloses that 
the file switch connects to a file server network through connections 110, 114 and other 
similar connections). 

As to claim 3, Miloushev teaches the communications network of claim I, further 
comprising a plurality of external network connections for facilitating a transfer of 
requests sent by said client computer to said communication virtualizer (Fig. 1 and [0124] 
disclose that the file switch connects to the client network 1 1 1 through connection 109). 

As to claim 4, Miloushev teaches the communications network of claim 1, further 
comprising a plurality of external connection paths for facilitating direct communication 
between said network-attached store computers and said client computer (Fig. 1 and 
[0125] disclose that the presence of file switch 100 is thereby preferably transparent to 
both the clients and the servers, therefore it facilitates direct communication between the 
network file servers and the clients). 
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As to claim 5, Miloushev teaches the communications network of claim 1, further 
comprising an Ethernet networking hardware and medium access protocol for facilitating 
communication within said communication network ([0122] discloses that the file switch 
is preferably equipped with multiple high-speed network interfaces, such as gigabit or 
higher Ethernet interfaces). 

As to claim 6, Miloushev teaches the communications network of claim 1, further 
comprising a Transmission Control Protocol / Internet Protocol suite for facilitating 
communication between said network-attached store computers and said client computer 
[0133] discloses that the file switch contains a TCP protocol stack). 

As to claim 7, Miloushev teaches the communications network of claim 1, further 
comprising a storage access protocol for facilitating communication between a storage 
component within said communications network and remaining components within said 
communications network ([0123] discloses that the file switch preferably supports 
multiple industry standard network file protocols, such as NFS and CIFS). 

As to claim 8, Miloushev teaches the communications network of claim 7, further 
comprising a storage access protocol that comprises a Network File System protocol 
([0123] discloses that the file switch preferably supports multiple industry standard 
network file protocols, such as NFS and CIFS). 

As to claim 9, Miloushev teaches the communications network of claim 7 
wherein said network further comprises a storage access protocol comprising a Common 
Internet File System (CIFS) protocol ([0123] discloses that the file switch preferably 
supports multiple industry standard network file protocols, such as NFS and CIFS). 
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As to claim 10, Miloushev teaches the communications network of claim 1, 
wherein said communication virtualizer comprises a network router ([0133] discloses that 
the typical operation of the file switch involves receiving file protocol requests, such as 
login, tree connect/mount, file open, file read/write, etc., from clients 1 12 and 113 and 
forwarding, or switching these requests to one or more of the file servers 101 through 
107, therefore the file switch has the function of a network router). 

As to claim 11, Miloushev teaches the communications network of claim 1, 
further comprising a communication virtualizer file switch connected to a client computer 
and a server computer for sending requests from said client computer to said network- 
attached store and from said network-attached store back to said client computer (Fig. 5 
and [0133] disclose that the file switch forwards client requests to the file servers; [0134] 
discloses that the file switch sends responses from the server back to the client ). 

As to claim 12, Miloushev teaches a method of communication over a 
communications network, said method comprising: 

sending requests for storage originated by at least one client computer over said 
communications network; 

receiving said requests for storage in at least one communication virtualizer; and 

transmitting the received requests for storage to a plurality of network-attached 
store computers connected to said communication virtualizer ([0133] discloses that the 
typical operation of the file switch involves receiving file protocol requests, such as 
login, tree connect/mount, file open, file read/write, etc., from clients 112 and 113 and 
forwarding, or switching these requests to one or more of the file servers 101 through 
107) 
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wherein said plurality of network-attached store computers are configured to 
appear as a single network-attached store computer (Fig. 1 and [0061] disclose that the 
file switch aggregates the namespaces of multiple independent file servers and presents 
them as a single, unambiguous namespace to network clients). 

wherein said requests for storage are transmitted as a series of packets, each 
packet comprising a portion of the request for storage ([0054] discloses that one aspect of 
the present invention is a network node that switches network protocol traffic by 
receiving the first network frame of a multiframe file protocol request, examining the file 
protocol header of that request, determining how or where the remaining frames of the 
request are to be forwarded and then forwarding each of those frames as it is received 
based on this determination) 

wherein each packet comprises a packet sequence number ([0125] disclose that 
clients request file services by communicating to the file switch 100 using the NFS or 
CIFS protocols that run on top of IP, it is inherent that an IP header contains a fragment 
offset, which is equivalent to the sequence number recited in the claim, see RFC 1094 
and RFC 791 for more information), 

wherein said packets comprising a similar request for storage are linked together 
using a request identifier (as said above that said packets are IP packets, it is then 
inherent that each IP header includes a sequence number that links multiple fragmented 
packets of a request together, so the sequence number is equivalent to the request 
identifier recited in the claim), said packet sequence number (the IP header of a packet 
inherently contains a fragment offset that identifies a fragment in a fragmented, multi- 
frame request), and a client identifier, 
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wherein each response packet from said store computers includes said client 
identifier(Fig. 3-5 and [0136] that the file switch does not handle transactions internally 
but, instead, examines the requests such as 205, optionally modifies request headers such 
as 200, and forwards the message to a file server. Because of this, the file switch 
preferably does not wait to receive all frames of a message such as 205 before 
forwarding it to the server. This allows the file switch to avoid introducing 
unacceptable latency on multi-frame file protocol transactions, such as 208. 

One of ordinary skill in the art of IP networking can reasonably derived from 
Miloushev's disclosure above that each frame 201, 202, 203 and 204 of the message 205 
carries the same source IP address in the IP header, where the source IP address identifies 
the client making the write request 205, and therefore is a client identifier. It can be 
further derived that the response from the file server for the write request carries the same 
client IP address in the destination IP address field of its IP header, i.e., the response 
includes said client identifier), 

and wherein each request for storage comprises a unique request identifier that is 
shared among said packets comprising said similar request (see above), 

transmitting, by said store computers, response packets to said communication 
virtualizer, wherein each of said response packets include said client identifier ([0134] 
discloses that the file switch sends responses from the server back to the client; the same 
reason as presented above regarding using client IP address as the client identifier applies 
here). 

As to claim 13, Miloushev teaches the method of claim 12, wherein said 
communication virtualizer, upon receiving requests from said client computer, transmits 
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said requests for storage to a chosen network-attached store computer based on a 
capability of said chosen network-attached store computer to properly process said 
request for storage ([0128] discloses that file switch can be divided into three broad 
categories: transaction handling (incl. transaction switching and transaction aggregation), 
file system aggregation (incl. aggregating file system objects and file data), and switch 
aggregation which includes various mechanisms for combining multiple file switches 
together (incl, load balancing, configuration sharing, failover and management 
aggregation). 

As to claim 16, Miloushev teaches the method of claim 12, wherein said network- 
attached store computer is configured for: 

receiving said requests for storage from said communication virtualizer ([0134] 
discloses that the TCP protocol stack on the server receives frames 201 through 204 as 
they arrive); 

processing said request for storage ([0134] discloses that the server waits until it 
has received the whole message 205 and then interprets the contents of the header 200, 
and executes the required operation, in this case a file write, by writing the data payload 
to the proper file); 

creating a corresponding response to said request for storage and sending said 
corresponding response to said communication virtualizer ([0134] discloses that upon 
completion, the server forms a response header 207 indicating the results of the requested 
operation). 

packetizing said corresponding response (it is inherent in IP network to packetize 

data); 
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sending said corresponding response to said communication virtualizer ([0134] 
discloses that the TCP protocol stack forms a network frame 206 containing the header 
207 and sends it to the client). 

As to claim 17, Miloushev teaches the method of claim 16, wherein said 
communication virtualizer is configured for receiving said corresponding response from 
said network-attached store computer; determining a chosen client computer to which 
said corresponding response should be routed to; and routing said corresponding response 
to a chosen client computer ([0144-0145] discloses that the file switch receives responses 
from the file server, processes them and then sends them to the client). 

As to claim 18, Miloushev teaches the method of claim 17, wherein said chosen 
client computer is configured for receiving said corresponding response from said 
communication virtualizer ([0144] discloses that the switch then examines the transaction 
reply header 400 and determines how to modify that header so that the client on 
connection 109 would accept the modified result as a valid response to the original 
request 205, which implies that the clinet is configured for receiving responses from the 
file switch); 

de-packetizing said corresponding response (it is inherent in TCP/IP network); 

and 

routing said corresponding response to an initiating application ([0123] discloses 
that the file switch preferably supports multiple industry standard network file protocols, 
such as NFS and CIFS, which implies that there must be a NFS or CIFS application on 
the client to receive and process responses to the requests). 



Application/Control Number: 10/767,593 Page 16 

Art Unit: 2144 

As to claim 19, Miloushev teaches the method of claim 15, wherein said packets 
are categorized from a zeroth (0th) packet to an ith packet ([0123] discloses that the file 
switch preferably supports multiple industry standard network file protocols, such as NFS 
and CIFS, which inherent implies that the requests are sent using IP; RFC 791 discloses 
the fragmentation technique used by Internet Protocol (IP) for data payload that's bigger 
than what the physical layer medium can support) 

As to claim 20, Miloushev teaches the method of claim 19, wherein said 
communication virtualizer determines which network-attached store computer to transmit 
said request for storage to by examining said zeroth packet in said request ([0137] 
discloses that upon receipt of the first frame 20 1 , which contains the request header 200, 
the switch 100 recognizes that this frame signifies the beginning of a new message, 
examines the header 200 and decides to which of the file servers to forward the whole 
message). 

As to claim 21, the Miloushev teaches the method of claim 19, wherein said 
client computer sends standard Ethernet packets to said communication virtualizer (0122] 
discloses that the file switch is preferably equipped with multiple high-speed network 
interfaces, such as gigabit or higher Ethernet interfaces). 

Miloushev does not specifically disclose but it is inherent in RFC 791 that the 
communication virtualizer combines a plurality of standard Ethernet packets comprising 
a single request for storage into a single packet comprising the request (RFC 791, 
Section 2.3 "Function Description" discloses that the recipient of fragmented IP packets 
re-assembles the fragmented packets into a single packet; In other words, the 
communication virtualizer' s build-in IP protocol combines a series of Ethernet packets 
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comprising a single request into a single packet; the communication virtualizer's build-in 
IP protocol further forwards the combined packet to the network-attached store computer 
as a single Ethernet packet if the physical medium connecting the said virtualizer and the 
NAS computer supports larger Maximum Transmission Unit (MTU), for instance, the 
MTU is 9000 bytes for Gigabit Ethernet.); 

As to claim 22, Miloushev teaches the method of claim 21. 

Miloushev further teaches that said network-attached store computer sends a 
standard Ethernet packet to said communication virtualizer in reply to a client computer's 
request (0122] discloses that the file switch is preferably equipped with multiple high- 
speed network interfaces, such as gigabit or higher Ethernet interfaces); 

Miloushev does not explicitly disclose but it is inherent in RFC 791 that said 
communication virtualizer dividing said standard Ethernet packet into a plurality of 
standard Ethernet packets to send to said client computer as a response comprising 
multiple standard Ethernet packets (RFC 791, Section 2.3 "Function Description" 
discloses that IP employs the fragmentation technique that segments large packets into a 
series of smaller packets of a size that the underlying physical medium supports, as each 
type of physical media has it own Maximum Transmission Unit (MTU) requirement; In 
other words, if the communication virtualizer receives from the network attached store 
computer as a response a single packet of large size, e.g., a jumbo Gigabit Ethernet 
packet of 9000 bytes, the IP protocol built into the communication virtualizer will divide 
said large packet into a plurality of standard 1500-byte Ethernet packets that is acceptable 
to the regular lOOMps Ethernet connecting the said virtualizer to client computers). 



Application/Control Number: 10/767,593 Page 18 

Art Unit: 2144 

As to claim 24, Miloushev teaches the communications network according to 
claim 1 , wherein said communication virtualizer is adapted to translate a first protocol of 
said requests for storage to a second protocol different from said first protocol ([0068] 
discloses an aspect of the invention which essentially is to translate a first protocol of 
requests from the client into a second protocol and forwards the translated request to the 
file server). 

As to claim 25, Miloushev teaches the communications network according to 
claim 1 , wherein said client computer sends standard Ethernet packets to said 
communication virtualizer (0122] discloses that the file switch is preferably equipped 
with multiple high-speed network interfaces, such as gigabit or higher Ethernet 
interfaces). 

Miloushev does not specifically disclose but it is inherent in internet protocol (IP) 
that the receiving device combines a plurality of standard, fragmented Ethernet packets 
comprising a single request for storage into a single packet comprising the request (RFC 
791, Section 2.3 "Function Description" discloses that the recipient of fragmented IP 
packets re-assembles the fragmented packets into a single packet; In other words, the 
communication virtualizer' s build-in IP protocol combines a series of Ethernet packets 
comprising a single request into a single packet; the communication virtualizer' s build-in 
IP protocol further forwards the combined packet to the network-attached store computer 
as a single Ethernet packet if the physical medium connecting the said virtualizer and the 
NAS computer supports larger Maximum Transmission Unit (MTU), for instance, the 
MTU is 9000 bytes for Gigabit Ethernet.); 
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As to claim 26, Miloushev teaches the method according to claim 12, The 
communications network according to claim 1, wherein said communication virtualizer is 
adapted to translate a first protocol of said requests for storage to a second protocol 
different from said first protocol ([0068] discloses one aspect of the invention which 
essentially is to translate a first protocol of requests from the client into a second protocol 
and forwards the translated request to the file server). 

Action is Final 

9. THIS ACTION IS FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of the 
advisory action. In no event, however, will the statutory period for reply expire later than 
SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to SHIRLEY X. ZHANG whose telephone number is 
(571)270-5012. The examiner can normally be reached on Monday through Friday 
7:30am -5:00pm EST. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, William Vaughn can be reached on (571) 272-3922. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO 
Customer Service Representative or access to the automated information system, call 
800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



/S. X. Z.I 

Examiner, Art Unit 2144 
02/26/2008 

/William C. Vaughn, Jr./ 

Supervisory Patent Examiner, Art Unit 2144 



